Make TcpConnectionSpec pull-mode reads deterministic#3321
Merged
Conversation
Motivation: TcpConnectionSpec assumed data written on the server side was immediately readable by the client before ResumeReading. Under load, the non-blocking client read could return zero and the fake selector never delivered the later ChannelReadable notification. Modification: Assert each test payload is written in full and wait for the client channel to become readable before each pull-mode ResumeReading command. Result: The test preserves its one-Received-per-pull assertions without depending on loopback delivery timing. Tests: - JDK 25 focused pull-mode test, 10 consecutive runs: passed - JDK 25 full TcpConnectionSpec: 35 passed, 0 failed - sbt headerCreateAll +headerCheckAll checkCodeStyle: passed - scalafmt --list --mode diff-ref=origin/main: passed - git diff --check: passed - Qoder stdout review: no must-fix findings References: Refs apache#3311
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
The
TcpConnectionSpecpull-mode test assumed data written on the server side was immediately readable by the client. Under load,ResumeReadingcould perform a non-blocking read before the data arrived; it then registeredOP_READ, but the test uses a probe as the connection selector and never delivered the laterChannelReadablenotification.Modification
Assert that each payload is written in full and use the test NIO selector to wait until the client channel is readable before each
ResumeReadingcommand.Result
The test still verifies that pull mode emits exactly one
Tcp.Receivedper pull while no longer depending on loopback delivery timing.References
Fixes #3311